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1. Introduction 

The goal of the National Institute of Standards and 
Technology (NIST) Process Specification Language 
(PSL) project (http://www.nist.gov/psl/) [1] is to create 
a process specification language that can be common to 
all manufacturing applications, generic enough to be 
decoupled from any given application, and robust 
enough to be able to represent the necessary process 
information for any given application. Additionally, 
the PSL should be sufficiently well defined to ensure 
complete and correct exchange of process information 
among established applications. 

The PSL project, with the help and feedback from 
colleagues in industry and academia, has come a long 
way since the first Roundtable in April 1997. Major 



accomplishments include: 1) determining the informa- 
tion requirements necessary for modeling manufactur- 
ing processes [1], 2) analyzing existing process repre- 
sentations to enable the comprehensive development of 
the Process Specification Language [2], 3) performing 
the first PSL pilot implementation in which PSL was 
used as an interlingua to integrate two manufacturing 
software applications [3], and most recently, 4) devel- 
oping a draft PSL Version 1.0 specification. 

The project reached an exciting and pivotal time in 
preparing to finalize Version 1.0 of PSL. Because a 
broad consensus was sought from those who have been 
involved or have followed the PSL work as well as 
those who will benefit from standards for process speci- 
fication, the PSL project sponsored a second Round- 
table on January 13-14, 1999 at the University of Mary- 
land, University College, College Park, Maryland. The 
attendee mix included 27 participants, representing an 
even mix of representatives from industry, academia, 
and government. 

The goal of the Roundtable was to discuss and come 
to consensus on the following three topics: 

1) Recap lessons learned from the first PSL pilot 
implementation and set the direction for future pilot 
implementations. 

2) Identify and review issues involved with mapping 
the PSL semantic concepts to existing textual repre- 
sentations (specifically, research performed map- 
ping to EXPRESS [4] and the extensible Markup 
Language (XML) [5]). 

3) Discuss the draft PSL Version 1.0 specification and 
come to consensus on the contents of the specifica- 
tion. 

Based on the consensus that was achieved at the 
Roundtable and building on results of the preceding 
phases of this project, the PSL project will shortly 
finalize the Version 1.0 specification of the Process 
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Specification Language and lay the groundwork for 
future pilot implementations to help continuously 
expand and improve the PSL specification. 

2. Roundtable Overview and Format 

The organization of the Roundtable was unique. 
There were actually two distinct portions of the event, 
the virtual and the physical portion of the Roundtable, 
where the virtual portion fed directly into the physical 
portion. 

2.1 Virtual Roundtable 

The Roundtable began on December 14, 1998 with an 
email discussion among the participants. The purpose 
of this email discussion was two-fold: 

• To allow participants to introduce themselves to the 
other participants. By doing this electronically, it 
allowed participants to jump directly into the tech- 
nical issues at the beginning of the physical 
Roundtable. 

• To allow participants to introduce issues they would 
like to see discussed at the physical Roundtable. This 
discussion allowed the PSL team to create an agenda 
that was directly in line with the participants' inter- 
ests while addressing the goal of discussing and 
coming to consensus on Version 1.0 of PSL and 
setting the direction for future pilot implementa- 
tions. 

Issues discussed during the virtual Roundtable in- 
cluded: 

• What other manufacturing-related fields have a 
strong need for a process specification language that 
the project should focus on in the future? 

• Have other groups attempted to develop mappings 
from well-defined semantic concepts to existing rep- 
resentations and how can those efforts be leveraged? 

• What types of representation would be best to 
provide mappings to? 

• What else can the PSL project do to make it easier 
for vendors to get involved? 

• Specific challenges involved with the mapping of the 
PSL semantic concepts to EXPRESS. 

In addition, papers and emails were sent out to allow 
colleagues who have not been closely involved in the 
project to get up-to-date quickly. 



2.2 Physical Roundtable 

The physical Roundtable began with an overview by 
C. Schlenoff (NIST), who discussed the goals of the 
Roundtable, described the Roundtable format, and gave 
a summary of the history and current status of the NIST 
PSL project. The rest of the day focused on a discussion 
of two topics, each of which was summarized, 
discussed, and followed by a written submission of 
participants' conclusions. 

The first topic, "Lessons Learned from the First PSL 
Pilot Implementation and Direction Setting for Future 
Pilots," was facilitated by Schlenoff. A summary and 
the results of the first PSL pilot implementation were 
presented and discussed [3]. In this pilot implementa- 
tion, PSL was used as a neutral representation to ex- 
change process information between the IDEF3-based 
ProCAP process modeling tool^ and the C++ based 
ILOG Scheduler. This presentation was followed by 
presentations from F. Tissot (KB SI) and M. Ciocoiu 
(University of Maryland). Both presentations focused 
on translation issues, with Tissot presenting a method- 
ology for translator writing and Ciocoiu focusing on the 
practical issues pertaining to translation. These presen- 
tations gave enough background of ongoing work to 
allow participants to discuss and answer the following 
questions: 

• What other manufacturing-related areas have a 
strong need for a process specification language that 
the project should focus on in the future? 

• What else can the PSL project do to make it easier 
for vendors/users to get involved? 

• What are the translation issues involved in using a 
formal ontology as an interchange language? 

The second topic, "A Review of the Draft PSL 
Version 1.0 Specification," was facilitated by 
M. Gruninger (University of Toronto). The goal of this 
topic was to discuss and come to consensus on the 
contents of the draft Version 1.0 specification. The 
session started with a presentation describing the 
current status of the specification. It also explained the 
decisions that were made along with the rationale. This 
presentation led to the discussion of the following 
questions: 



^ Certain commercial equipment, instruments, or materials are identi- 
fied in this paper to foster understanding. Such identification does not 
imply recommendation or endorsement by the National Institute of 
Standards and Technology, nor does it imply that the materials or 
equipment identified are necessarily the best available for the pur- 
pose. 
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• Are the concepts introduced in the draft Version 1.0 
specification an appropriate foundation to model 
manufacturing process information? 

• Are the definitions of those concepts in line with 
users' intuitions? 

• Are the concepts presented and organized in a way 
that would make it easy for a user to understand? 

At the end of the first day, a brief discussion ensued 
focusing on the ontology management challenges that 
were brought to light in previous discussions. Topics 
discussed included: 

• Issues with respect to version control of extensions. 

• A policy for submission and review of proposed 
extensions. 

• What should be contained in a header file for PSL 
extensions? 

• Tools and/or techniques that would make it easier for 
a user to view/navigate through the PSL concepts. 

On the second day, the third topic, "Issues Involved 
With Mapping the PSL Semantic Concepts to Existing 
Representations," was facilitated by J. Valois (STEP- 
Tools, Inc.) The session started with a very brief 
overview by Schlenoff describing the purpose of the 
exercise of mapping PSL to existing representations. 
Briefly stated, the underlying representation of PSL (the 
Knowledge Interchange Format (KIF) [6]), although 
very appropriate for this work, is not very human-read- 
able. For this reason, efforts are underway to map the 
concepts represented in KIF into existing representa- 
tions that are easier for a human to read and understand. 
This session continued with presentations from J. Valois 
(STEPTools Inc.) and J. Lubell (NIST) describing their 
work in mapping the PSL concepts to EXPRESS [4] 
and the extensible Markup Language (XML) [5], 
respectively. These presentations primed the audience to 
address the following questions: 

• What other representations, aside from EXPRESS 
and XML, would be useful to provide mappings to? 

• What is the best mechanism for providing these 
mappings? 

At the conclusion of this topic, decisions were made on 
how to proceed and the Roundtable concluded. 



3. Roundtable Details and Results 

The Roundtable was broken up into three sessions, 
each focusing on specific technical issues facing the 
PSL development. These issues include: 1) translation 
issues and future direction for the project, 2) content and 
structure issues relating to the release of PSL Version 
1.0, and 3) issues pertaining to the mapping of semantic 
concepts to existing presentations. In addition, a sepa- 
rate, short session was held at the end of the first day to 
discuss management issues pertaining to the growth of 
the PSL ontology. 

3.1 Topic 1: Lessons Learned from the First Pilot 
Implementation and Direction Setting 

This topic started out with a description of how PSL 
was used to integrate the IDEF3-based ProCAP process 
modeling tool and the C++ based ILOG Scheduler [3]. 
In this pilot implementation, the process-related con- 
cepts from each of these applications were identified, 
formally defined and captured within the PSL Ontology. 
Then, two translators were written that 1) translated the 
concepts in ProCAP into the existing and newly defined 
concepts in PSL, and 2) translated the concepts in PSL 
into the ILOG representation. For this pilot implementa- 
tion, a scenario developed by Ken McKay, as part of his 
work with Consortium for Advanced Manufacturing — 
International (CAM-I), was used [7]. This scenario, 
nicknamed the "factory from hell," describes the goals, 
constraints, and issues faced by a fictitious motor works 
factory in developing model cars. The content of the 
scenario was inspired from insights gained from visits to 
real factories. 

Following this, work was presented describing 
methodologies and practical considerations when using 
PSL for translation. These presentations not only 
described on-going work but also raised some issues 
that NIST is currently trying to address. A description of 
these issues and the pertinent discussion can be found in 
Sec. 3.1.3. 

3.1.1 Scope and Purpose of PSL 

Before one can start talking about detailed issues with 
respect to translation and deciding on future directions, 
it is important to clarify what the scope and purpose of 
PSL will be. Although all agreed that the ultimate goal 
of PSL was for information exchange, there 
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were a number of different opinions regarding other 
ways in which it could be used. These included: 

• As a generic process representation language. 

• As a "capability reference for methods" that would 
allow a target application to inherit PSL's formal 
mechanics. 

• The high level concepts of PSL could be used to 
model process in multiple domains and even inte- 
grate multiple domains at the highest level of pro- 



In general, it was decided that PSL could be used for any 
of these purposes as long as it did not compromise its 
ability to serve as an exchange representation. 

With respect to scope, there was a large amount of 
concern from the participants that the PSL project has 
not yet set bounds on what will be included and what 
will not be included. Various participants disagreed on 
whether certain types of information should be included 
in the language. These were: 

• When (the actual time and date) an activity should 
begin 

• Concepts related to decision support 

• "How" the process will occur. 

In general, it was decided that PSL is meant to repre- 
sent enough information about a process so that it could 
be used however necessary. It is not the goal of PSL to 
dictate exactly when or how a process happens, this is 
up to the decision structure of the individual company. 
PSL must only be able to represent enough information 
about the process to allow this type of activity to take 
place. 

Another issue that arose is how "deep" PSL should go 
with respect to modeling process information. Is it the 
job of PSL to model the details of process specification 
for any specific domain? For example, should PSL 
model the details of the activities that take place in a 
specific manufacturing operation (e.g., should a concept 
exist that defines drilling, sanding, etc.) or is this at a 
level of detail that is too deep for the scope of PSL. It 
was generally decided that the PSL standard would most 
likely not include concepts for these types of operations. 
General activity concepts presented in the PSL standard 
could be easily extended by the user in specialized 
extensions to capture these concepts. However, if done 
properly, these extensions could find their way into the 
standard in the future. 



3.1.2 Proprietary Issues 

Another concern communicated dealt with the pro- 
prietary nature of process information. In general, the 
way that a company performs a process is what gives it 
an advantage over other competing companies. There- 
fore, companies are very reluctant to make available 
these proprietary secrets. 

However, with the growth of "virtual enterprises," 
companies are working more closely together and 
sharing information. Process information will be one of 
the many types of information being shared. How can a 
company share necessary information without giving 
away their proprietary advantage? 

One way that PSL could help with this is to be able to 
represent information at different levels of abstraction. 
In this way, only information that is necessary could be 
represented and it could be generalized in a way that 
would still convey the necessary information without 
going into a level of detail that would infringe on a 
company's advantage. It was therefore suggested that 
PSL be developed with this type of architecture in mind. 

3.1.3 Translation and Human Interaction Issues 

It was suggested that in order to get PSL accepted by 
industry, PSL must minimize the work a company 
would need to perform to be "PSL compliant." This 
would involve making the language easy to read and 
understand and allowing for quick and seamless transla- 
tor development. 

The overwhelming consensus was that an extensive 
set of documentation, tutorials, figures, and numerous 
examples would be extremely beneficial. One partici- 
pant emphasized that "the documentation should be 
written such that "non-geeks" can understand and im- 
plement PSL." Other participants suggested that soft- 
ware would be useful to shield a user from having to 
interact directly with the logic side of PSL. Most felt 
that although the formal logic side of PSL was essential 
for this work, it was not something with which a user 
should directly interact. 

3.1.4 Approach and Future Direction 

This discussion focused on evaluating the approach 
the PSL project has been taking and on determining in 
what direction the project should proceed. In general, 
most participants felt that the project's approach had an 
appropriate mix of theoretical and pragmatic consider- 
ations. However, with the upcoming release of the final- 
ized PSL Version 1.0 Specification, there were strong 
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concerns that the project would need to focus more 
heavily on the practical issues pertaining to using PSL 
as an exchange specification. One participant suggested 
that directions pursued by STandard for the Exchange of 
Product model data (STEP), officially ISO 10303 [8], 
might be appropriate for this project. This suggestion is 
being explored. 

In general, there seemed to be two suggested direc- 
tions in which the project could proceed. The first dealt 
with expanding the current ontology to incorporate con- 
cepts in manufacturing-related fields that have not yet 
been explored. Specific suggested fields included: 

• Concurrent Engineering 

• Supply Chain Management 

• Manufacturing Resource Planning 

• Business Processes 

• Virtual Enterprise Composition Process 

• Activity Based Costing 

• Generating Bids 

• Agent-Based Systems 

• Design for Manufacturing 

The second direction focused more on ensuring that 
the current concepts within PSL are sufficient to com- 
pletely capture the manufacturing fields that have been 
explored. In other words, when PSL was extended to 
capture scheduling information, only a single schedul- 
ing tool was studied. Perhaps the PSL members should 
go back and explore other scheduling tools to ensure 
more scheduling-related concepts are captured. One 
participant captured this well when he said "PSL should 
explore the portability and determinism of the process 
specification (e.g., making sure what is there is 
'correct')." 

3.2 Topic 2: Discussion of Draft Version 1.0 

The goal of the second topic was to present and dis- 
cuss the draft PSL Version 1.0 specification with the 
hope of coming to consensus on the content of the 
release. The discussion focused on two main topics: the 
content of PSL and the relationship of PSL to other 
models. Both topics are discussed below. 

3.2.1 Content of PSL 

For the most part, the participants were very satisfied 
that the content of the proposed PSL Version 1.0 is 
appropriate for the release. However, discussion did en- 
sue focusing mostly on the types of information that 
participants expected to see in the PSL specification 



that were not apparent. These included (in no particular 
order): 

• Information which is contextual (e.g., external) not 
for translation but as "information fields" for valida- 
tion and other introspective tasks 

• The representation of uncertainty (e.g., this process 
has a probable duration and a possible range) 

• Pointers to other models which contain information 
that is related to process specification (e.g., STEP'S 
Part 49 (Process Structure and Properties) and Ap- 
plication Protocol 213 (Numerical Control Process 
Plans for Machined Parts) 

• Conditions (start and end) 

• Representation of inverse causality (e.g., given a set 
of processes, what type of product can be made) 

• Representation of inputs and outputs 

• Further classification of activity, with appropriate 
definitions, to model transformation, assembly, and 
disassembly activities 

• Activity dependencies via data 

• Procedural information (e.g., rules) 

• State and control 

• The relationship between plans and part numbers 

• Assembly process 

• Spatial information. 

Some of the concepts listed above are already being 
researched to be included in PSL, some have not, al- 
though many will most likely find their way into PSL 
during later releases. This discussion will prompt the 
PSL team to look over the PSL specification and deter- 
mine which of these concepts should be included in the 
Version 1.0 of PSL. In addition, it strengthened the point 
mentioned earlier that the document for PSL needs to be 
very clear and easy to read such that a user can easily 
determine if the concept they are looking for is currently 
captured in PSL. 

3.2.2 Relationship to Other Models 

It was widely accepted that the goal of PSL is not to 
model process-related information that already appears 
in other information models. Instead, there should be a 
link from PSL to other supporting representations, 
when and where appropriate. There could be a number 
of different representations related to PSL, including: 

• A product representation model 

• A process characterization model 
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• A resource description model 

• A business practices model 

One of the main discussions in this session dealt with 
how to best integrate PSL and STEP. For example, when 
one is trying to describe assembly information, how 
much does one describe in PSL and how much does one 
leave up to STEP? STEP already has concepts such as 
"next-higher-assemblies," so there is no need to model 
that type of concept in PSL. 

Another issue is the method in which the information 
would be linked. For example, one could link STEP and 
PSL via standardized methods: EXPRESS, Part 21 (the 
textual exchange mechanism), or the Standard Data 
Access Interface (SDAI), or one could link the informa- 
tion via other standards (various parts of STEP which 
deal with process information). It was suggested that 
one mechanism for determining the best approach is 
to look at the enterprise modeling efforts ongoing in 
numerous standards' bodies and leverage their work. 

Lastly, there was some discussion as to where PSL 
stops and where a process characterization model be- 
gins. A process characterization model would describe 
the details of an activity independent of a specific appli- 
cation. For example, PSL would simply reference an 
activity and describe some of its high level characteris- 
tics while a characterization model would describe more 
detailed aspects such as the dynamics/kinematics of that 
activity, tool chatter, etc. There was little doubt that 
these two models would work together; the concern 
was where to draw the boundaries. Although these 
boundaries are still fuzzy, there seemed to be a lot of 
interest among the participants for NIST to explore 
the creation of a process characterization model (as a 
separate project). 

3.3 Topic 3: Mapping of the PSL Semantic 
Concepts to Existing Representations 

The goal of the third topic was to make the partici- 
pants aware of the work that was going on within the 
PSL project in mapping the PSL semantic concepts to 
the XML and EXPRESS representation with the hope of 
resolving issues that arose during this mapping. In 
addition, a sub-goal of this topic was to identify other 
representations that may be appropriate to map to. 
Briefly stated, the underlying representation of PSL 
(i.e., KIF), although very appropriate for this work, is 
not very human-readable. For this reason, efforts are 
underway to map the concepts represented in KIF into 
existing representations that are easier for a human to 
read and understand. The discussion seemed to fall 
neatly into two separate topic areas: the role of presenta- 
tions and specific issues with respect to the mapping 



to EXPRESS. The discussions of these topics are 
described below. 

3.3.1 Roles of Presentations 

Although originally grouped together, the partici- 
pants identified two distinct, yet equally important, 
types of presentations. They are: 

1. A presentation that is logically equivalent and 
equally as expressive as KIF but easier to look at and 
understand (e.g., conceptual graphs). 

2. A presentation that is prototypical to a whole range 
of applications (e.g., EXPRESS, XML). 

The first type of presentation would fulfill the origi- 
nal requirement that was stated for a presentation; 
namely, that it would represent all of the concepts repre- 
sented in the PSL Ontology yet provide a more user- 
friendly way for users to read and understand the con- 
tents of the language. This presentation would be sound 
and complete with respect to the PSL Ontology. It would 
also provide a read/write capability that would allow a 
user to only interact with an easy-to-read, graphical 
interface while still having the capability to edit the 
contents of the ontology. 

The second type of presentation would provide a 
completely different set of purposes. These purposes 
include: 

• providing a link to other user communities that are 
interested in PSL and are already accustomed to 
interacting with a different type of presentation 
(e.g., EXPRESS for the STEP community) 

• allowing PSL to utilize an established set of tools 
and techniques that are already available in other 
communities but rely on a different syntactic re- 
presentation (e.g., EXPRESS tools developed by 
various vendors) 

• providing a mapping to commonly used representa- 
tions to facilitate the act of translator writing for 
tools that use these representations (e.g., by creating 
a mapping to XML, all tools that use XML as their 
underlying representation will easily be able to write 
translators to PSL by basing it on the mapping). 

This type of presentation will be sound but not neces 
sarily complete with respect to the PSL ontology and 
will be used primarily for read-only purposes (e.g., to 
view the contents of the ontology). 

Although originally grouped together, both of these 
types of presentations are going to be pursued in the 
PSL project. 
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3.3.2 Specific Issues Pertaining to Mapping 
to EXPRESS 

The presentation describing the mapping of the PSL 
semantic concepts to EXPRESS seemed to generate a 
fair amount of concerns. In this presentation, a descrip- 
tion of the methodology used to map each concept in the 
PSL Ontology to a construct in EXPRESS was 
described. In addition, a description of how this 
mapping would involve the use of EXPRESS-X [9] and 
EXPRESS was presented. Some of the comments 
voiced by the participants included: 

• All concepts (and their extensions) introduced in 
PSL should be directly modeled in EXPRESS, not 
represented as strings. 

• The EXPRESS model should be as close as possible 
to the KEF model in structure. Also, the terminology 
in the EXPRESS model should only be that used in 
KIR 

• Should the project use experimental information 
technology (EXPRESS-X, EXPRESS-2) for map- 
ping to presentations? 

These considerations, among others will be taken into 
account during the second pass of the mapping effort. 



3.4 Additional Topic: 
PSL Ontology 



Management of the 



Although not originally scheduled as a topic for this 
Roundtable, the participants seemed to voice a fair 
amount of concerns about how the growth of PSL would 
be handled in the future. Management of the PSL Ontol- 
ogy was identified as one of the most important aspects 
of the project to ensure PSL's success. Briefly stated, 
PSL already contains over 300 concepts, about 30 exten- 
sions and has multiple people involved in developing 
new extensions. Considering the rate at which PSL is 
expected to grow, there needs to be mechanisms in place 
to facilitate this growth. For example, it was identified 
that the following should be explored: 

• Mechanisms for version control of extensions in the 
Ontology. 

• Mechanisms for a review process to ensure that 
newly proposed extensions are consistent with the 
current extensions and appropriate. 

In addition, there were numerous opinions pertaining 
to how PSL should grow. For example, some partici- 
pants thought that the growth of the extensions should 
focus on domains (e.g., assembly, material removal, 
etc.) while others thought PSL should focus on various 
applications in the life-cycle (e.g., planning, scheduling. 



simulation). Currently, the PSL project is taking a more 
life-cycle approach although it is keeping an eye on how 
this would feed into a domain-specific approach. 

4. Conclusions and Future Directions 

The goal of the PSL Roundtable was to assemble 
experts in the process representation community to 
come to consensus on the content of the current state of 
the PSL and to determine the project's future direction. 
These goals were in fact achieved with the overall 
consensus on the contents of the proposed Version 1.0 
specification (with a few minor additions) and with the 
identification of a set of application areas and directions 
that the project should pursue. 

One of the most striking aspects of the Roundtable 
was the diversity of background of the people that 
attended. Almost all participants had a slightly different 
interpretation of how the PSL could be used and tailored 
to suit their needs. These interpretations ranged in usage 
from an exchange specification, to an underlying repre- 
sentation, to a "capability reference for methods" that 
would allow a target application to inherit PSL's formal 
mechanics. Pertaining to domains of usage, PSL was 
suggested for use in business, control, simulation, 
assembly, and healthcare applications. 

Many of the participants in the Roundtable discussion 
showed great interest in seeing this project continue and 
are even tailoring their work to incorporate the use of 
PSL as it matures. 

These next few months will be a very exciting time 
for the PSL project, building off of the results of the 
discussion at the Roundtable. Within this time, the PSL 
effort will be releasing Version 1 .0 of the PSL specifica- 
tion, re-assessing the contents of the language to ensure 
its complete coverage of manufacturing domains that 
have already been addressed, performing another pilot 
implementation to continually expand the robustness 
and usefulness of the language, and proposing PSL as 
an international standard. 

Acknowledgments 

This workshop was funded by NIST's Systems 
Integration for Manufacturing Applications (SIMA) 
Program. Initiated in 1994 under the Federal Govern- 
ment's High Performance Computing and Communica- 
tions effort, SIMA is addressing manufacturing systems 
integration problems through applications of informa- 
tion technologies and development of standards-based 
solutions. With technical activities covering a broad 
spectrum of engineering and manufacturing domains, 
SIMA is making information interpretable among 
systems and people within and across networked 
enterprises. 



501 



Volume 104, Number 5, September-October 1999 

Journal of Research of the National Institute of Standards and Technology 
5. References 

[1] C. Schlenoff, A. Knutilla, and S. Ray, Unified Process Specifica- 
tion Language: Requirements for Modeling Processes, NISTIR 

5910, National Institute of Standards and Technology, Gaithers- 

burg, MD (1996). 
[2] A. Knutilla et al.. Process Specification Language: An Analysis 

of Existing Representations, NISTIR 6133, National Institute of 

Standards and Technology, Gaithersburg, MD (1998). 
[3] C. Schlenoff et. al.. Process Specification Language (PSL): 

Results of the First Pilot Implementation, submitted to the ASME 

International Mechanical Engineering Congress and Exposition 

(IMECE), November 1998. [4] ISO 10303-1 1: 1994, Product data 

representation and exchange: Part 11: EXPRESS language refer- 
ence manual. 
[5] W3C Architecture Domain, Extensible Markup Language 

(XML), http://www.w3c.org/XML/, November 17, 1998. 
[6] M. Genesereth and R. Fikes, Knowledge Interchange Format 

(Version 3.0)— Reference Manual, Computer Science Dept., 

Stanford University, Stanford, CA (1992). 
[7] K. McKay and J. Moore, CAM-I (Consortium for Advanced 

Manufacturing International) Report: Intelligent Manufacturing 

Management Program: State of the Art Scheduling Survey 06-23- 

91, Technical Report R-91-IMM-01 (1991). 
[8] ISO 10303-1:1994, Product data representation and exchange: 

Part 1: Overview and fundamental principles. 
[9] ISO TC184/SC4/WG11/N002, EXPRESS-X Reference Manual, 

Working Draft, August, 1996. 

About the author: Craig Schlenoff is a mechanical 
engineer and program leader in the Manufacturing 
Systems Integration Division of the NIST Manufactur- 
ing Engineering Laboratory. The National Institute 
of Standards and Technology is an agency of the 
Technology Administration, U.S. Department of 
Commerce. 



502 



